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ABSTRACT 

Ginga is the middleware for SBTVD, the Brazilian Digital 
TV System. The purpuse of this study is to extend Ginga, 
creating a software component that enables it to communi- 
cate in a peer-to-peer network, and exposing an API that 
developers can use to exchange files and messages in the 
Ginga ecossystem without the need to explore the details of 
peer-to-peer communication. This required understanding 
of the workings and stmcture of the middleware and devel- 
opment tools, and also the investigation of possible protocols 
for file and message exchange in the new component. This 
work resulted in the adoption of the XMPP-Jingle protocol 
in a prototype component, its specification and a test case, 
showing the middleware’s proneness to be componentized 
for use in non-conventional applications. 
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l. INTRODUÇÃO 

A televisão digital está sendo implementada em todo o 
território nacional, com isso, novos recursos são disponibi- 
lizados, entre eles a possibilidade de interação com os pro- 
gramas transmitidos, a partir de aplicações desenvolvidas 
para esse fim. A comunicação ponto- a-ponto entre os espec- 
tadores permite a colaboração e troca de arquivos, um novo 
recurso disponível a ser explorado pelos desenvolvedores das 
aplicações para TV Digital Interativa (TVDi). 
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Ginga é o nome do Middleware Aberto do Sistema Brasileiro 
de TV Digital (SBTVD). A Rede Nacional de Pesquisa (RNP) 
é a incubadora do programa Centro de Pesquisa e Desen- 
volvimento em Tecnologias Digitais para Informação e Co- 
municação (CTIC) 1 , a qual propôs uma série de tarefas 
para o desenvolvimento do middleware dentro do projeto 
intitulado: GingaFrEvo e GingaRAP - Evolução do Mid- 
dleware Ginga para Múltiplas Plataformas ( Componentiza- 
ção ) e Ferramentas para Desenvolvimento e Distribuição de 
Aplicações Declarativas. O projeto é subdivido em Gin- 
gaRAP, destinado ao suporte a autoria de aplicações, e Gin- 
gaFrEvo, um framework de evolução da tecnologia Ginga, e 
é realizado em conjunto com várias universidades e coorde- 
nado pelos laboratórios Telemídia da Pontifícia Universidade 
Católica do Rio de Janeiro (PUC-Rio) e o Laboratório de 
Aplicações de Vídeo Digital (LAViD) da Universidade Fed- 
eral da Paraíba (UFPB) [6]. 

Inserido no GingaFrEvo está o GingaAiyê, especialização 
do Ginga-CC (Ginga- Common Core ) para aplicações não 
convencionais. Ginga-CC é o nome dado a um dos grandes 
módulos do middleware Ginga, o Núcleo Comum, que será 
abordado mais a frente neste trabalho. Uma das motivações 
para o GingaAiyê é a demanda pela padronização do middle- 
ware Ginga para plataformas de IPTV, Internet TV e P2P 
TV, abrindo a possibilidade para que os usuários realizem 
atividades colaborativas por meio da Internet [6] . 

Nos computadores a troca de arquivo entre usuários é um 
elemento essencial para a colaboração, seja por e-mail ou re- 
des de compartilhamento. Com atenção a esse potencial, o 
desenvolvimento da interatividade da TV Digital deve ofer- 
ecer tal recurso, de modo que desenvolvedores terão mais 
uma importante ferramenta, que possibilitará o surgimento 
de aplicações mais interessantes para a televisão. Esse tra- 
balho tem como objetivo descrever a especificação e imple- 
mentação iniciais de um componente P2P que proporcione 
a colaboração entre usuários via servidores apropriados. 

O documento está estruturado da seguinte forma: a Seção 
2 introduz a área explorada, protocolo e biblioteca utilizada 
no trabalho. A Seção 3 mostra detalhes da arquitetura do 
middleware Ginga e como o trabalho foi realizado. Por fim, 
a Seção 4 apresenta o resultado obtido. 

2. SISTEMAS DISTRIBUÍDO P2P 

Sistemas distribuídos são classificados em Cliente/Servidor 
e Peer-to-Peer. Um sistema Cliente/Servidor consiste em 
um sistema de alta performance, o servidor, e vários outros 
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sistemas de performance mais baixa, os clientes. O servi- 
dor é o provedor de conteúdo e serviço. Um cliente requi- 
sita por conteúdo ou execução de serviços, sem compartil- 
har qualquer de seus recursos. Recursos podem ser poder 
de processamento, capacidade de armazenamento de dados, 
impressoras, entre outros; serviços são compartilhamento de 
arquivos, por exemplo. 

Um sistema distribuído é considerado Peer-to-Peer se os 
membros compartilham parte dos seus recursos. Esses re- 
cursos são necessários para prover o serviço e conteúdo ofer- 
ecido pela rede e devem ser acessados pelos outros peers 
diretamente, sem passar por entidades intermediárias. Os 
participantes desse tipo de rede são provedores bem como 
requisitantes destes de serviços e conteúdos. Em P2P puro 
não há a existência de nenhuma entidade para prover recur- 
sos ao sistema distribuído [5] . 

2.1 Protocolo XMPP-Jingle 

Foi concebido em 1999, o protocolo extensível de Men- 
sagens e Presença, Extensible Messaging and Presence Pro- 
tocol (XMPP), era anteriormente conhecido por Jabber, nome 
da comunidade open-source que iniciou o projeto como um 
padrão aberto para comunicação em tempo real. O desen- 
volvimento do XMPP foi motivado pela carência de um pro- 
tocolo aberto para troca de mensagens instantâneas. 

Aplicativos XMPP são capazes de oferecer os serviços de 
criptografia de canal, autenticação, presença, lista de con- 
tatos, mensagens um-a-um ou em grupo, notificações, de- 
scoberta de serviço, controle de fluxo e seções multimídia. 

Os serviços estão definidos nas especificações publicadas 
pela Força Tarefa de Engenharia de Internet 2 ( Internet En- 
gineering Task Force - IETF), e suas extensões nos Padrões 
Estabelecidos XMPP 3 , da XMPP Standards Foundation. 

A extensão Jingle é usada para inicializar e administrar 
sessões multimídia entre duas entidades, de maneira interop- 
erável com os padrões da Internet [3]. Devido a utilização 
do procotolo XMPP juntamente com a extensão Jingle, este 
trabalho refere-se a XMPP-Jingle sempre mencionando o 
uso de ambas implementações. 

Stanzas são para XMMP o que o pacote é para a camada 
de rede do modelo OSI/ISO, ou seja, uma estrutura enviada 
entre os dois pontos (entidades) que estão se comunicando. 

2.1.1 Como XMPP funciona 

A arquitetura da rede XMMP é descentralizada e baseada 
em client e/servidor, ou seja, a comunicação não é feita dire- 
tamente entre os clientes, semelhante ao serviço de e-mail. 
Quando um cliente de e-mail envia uma mensagem, a mesma 
é enviada ao servidor do destinatário, como um pacote de 
rede, a mensagem trafega entre os servidores de e-mail inter- 
mediários. O serviço de XMPP funciona de maneira difer- 
ente, os clientes se conectam aos servidores, que por sua vez 
se conectam entre si. Aqui os servidores onde os clientes 
estão conectados trocam dados diretamente, sem passar por 
nenhum outro servidor XMPP ( [hop ) intermediário . 

As contas dos usuários da rede XMPP são identificadas 
por um JabberID (JID) que possui a forma de um endereço 
de email, ou seja, nomedousuario@servidor.tdl , inclusive po- 
dendo ser o próprio endereço de e-mail, caso o servidor 
forneça ambos serviços. Um exemplo disto é o GMail da 

2 http://ietf.org/ — acesso em 25/05/2010 

3 http://xmpp.org/ — acesso em 25/05/2010 



Google Inc. 4 

Um usuário pode se conectar à rede através de múltiplos 
dispositivos concorrentemente, a cada conexão um resource é 
designado pelo servidor, ou definido pelo usuário, para servir 
de identificação e roteamento das mensagens. Dessa forma, 
quando, por exemplo, um usuário inicia através do celular 
uma conversa com um amigo, o mesmo responde e esta men- 
sagem é encaminhada para o telefone, e não qualquer outro 
elemento conectado na rede, com resource diferente. 

2.2 Biblioteca libjingle 

Implementação do protocolo Jingle feita pela Google Inc., 
distribuída em código aberto. A especificação da extensão 
Jingle ainda está classificada como draft (não concluída) e 
portanto a libjingle não provê compatibilidade com outros 
sistemas que se utilizam da versão atual da especificação, 
uma vez que o desenvolvimento da biblioteca ocorreu par- 
alelamente com as primeiras revisões da especificação. 

2.2.1 Estrutura de aplicações com libjingle 

A estrutura de um programa que se utiliza da biblioteca 
libjingle possui, além da interface com o usuário, três grandes 
componentes [2], que são: 

XMPP Messaging Component : Componente de mensagens 
XMPP, serve como um gateway entre a rede (represen- 
tada no diagrama pela nuvem) e as stanzas que chegam 
do Componente de Lógica e Gerenciamento da Sessão; 

Session Logic and Management Component : Componente 
de Lógica e Gerenciamento da Sessão, cuida da lógica 
de cada tipo de sessão, é o responsável por passar stan- 
zas para o componente Ponto- a- Ponto, que cuidará dos 
detalhes da conexão, e depois irá ler /escrever os da- 
dos do componente para arquivos, sistema de audio ou 
vídeo; 

Peer-to-Peer Component: Componente Ponto- a-Ponto, re- 
sponsável por cuidar dos detalhes da conexão entre os 
pontos, alocando sockets e monitorando a qualidade 
da conexão. 

O tráfego de dados é realizado Ponto- a- Ponto, diretamente 
entre os clientes que estão trocando arquivos, por exemplo. 
Assim o servidor XMPP é responsável pelo envio e recebi- 
mento das stanzas que anunciarão a troca P2P, mas os dados 
não passam pela rota do servidor. 

3. IMPLEMENTAÇÃO NO MIDDLEWARE 
GINGA 

A partir do código-fonte da aplicação pcp que acompanha 
o SDK da biblioteca libjingle foi construído o componente e 
a aplicação de exemplo. A Seção 3.1 apresenta a arquitetura 
do middleware Ginga. A Seção 3.2 mostra de que forma está 
implementada no middleware o componente e a aplicação 
teste. 

3.1 Arquitetura do Ginga 

A arquitetura do middleware Ginga é formada por três 
grandes módulos, o ambiente declarativo Ginga-NCL, o am- 
biente imperativo Ginga-Imp e o núcleo comum Ginga-CC. 

4 Os serviços de DNS são usados pelo XMPP para os fins de 
resolução de domínios 




O Núcleo Comum do middleware Ginga provê as funcionali- 
dades comuns aos outros dois ambientes e é composto pelos 
decodificadores de conteúdo comuns e por procedimentos de 
obtenção de conteúdo dos fluxos de transporte, Transport 
Streams (TS), MPEG-2 e outras redes suportadas pelo sis- 
tema operacional do receptor onde o middleware Ginga está 
instalado. Além disso Ginga-CC deve suportar o modelo de 
exibição, controle de acesso condicional, gerenciamento de 
contexto, persistência de objetos de multimídia e gerencia- 
mento de atualizações. 

Aplicações de Televisão Digital Interativa (TVDi), podem 
ser puramente declarativas (escritas em NCL), puramente 
imperativas ou híbridas. O documento inicial aceito pelo 
middleware pode ser escrito para qualquer um dos ambi- 
entes citados. Aplicações podem ser recebidas das várias re- 
des disponíveis, entre elas o carrossel de dados da emissora, 
fluxo contínuo de dados pelo protocolo do padrão MPEG- 
2-TS, ou aplicações residentes. Os componentes do Núcleo 
Comum, além de serem utilizados pelos ambientes declara- 
tivo e imperativo, podem ser utilizados por aplicações vindas 
de qualquer fonte. 

A Figura 1 mostra a Arquitetura do middleware Ginga 
com seus módulos e ambientes declarativo e imperativo. 
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Figure 1: Arquitetura do Ginga [1] 



3.2 Codificação do Componente e aplicação teste 

A Figura 2 mostra o diagrama de classes do componete 
P2P e da aplicação de teste, um detalhe de implementação 
é a necessidade da aplicação herdar a classe 
: : br : :pucrio: itelemidia: : ginga: :core: : system: :thread: : 
Thread para que o middleware Ginga não trave esperando a 
execução da mesma. 



br.usp .ícmc .intermidia ;n vy, [ . : • 



P2PTest 



br . usp . ícmc . íntermdia . ginga , core , p2p| 



IP2PManager 



-2> P2PManager FileShareClient 



Figure 2: Diagrama de classes do componente e apli- 
cação teste 

A classe P2PTest possui o método run(), sua implemen- 
tação instancia um objeto da classe P2PManager do compo- 
nente. Essa classe tem o método connect(), responsável pela 



conexão com servidor XMPP e chamada dos métodos imple- 
mentados na classe FileShareClient , responsável por realizar 
a troca de arquivos. 

A classe P2PTest é uma estrutura Singleton , um padrão 
de projeto que restringe a criação de apenas uma instância 
da classe. O código- fonte de P2PTest mostra isso no método 
getlnstanceO , o cronstrutor da classe possuia rotina de log 
usada pelo middleware Ginga. O método run() configura al- 
guns detalhes para a conexão e em seguida chama o método 
connectO da classe P2PManager. 

P2PManager também é uma classe Singleton , seu método 
connect () é responsável por criar a conexão XMPP e preparar 
parâmetros para a instância de FileShareClient. 

A classe FileShareClient implementá a extensão Jingle, a 
restruturação para a ampliação da API do componente se 
dará a partir desta classe, que concentra todo o serviço de 
troca de arquivos. 

4. CONCLUSÕES 

O aplicativo pcp, parte da SDK da libJingle , foi configu- 
rado com uma conta XMMP diferente da aplicação de teste 
do componente, dentro do middleware para a demostração 
de envio de um arquivo deste cliente até o middleware Ginga. 

A execução do middleware Ginga imprime no terminal 
da máquina virtual logs , que foram utilizados pra confirmar 
a execução da aplicação, e a partir disso foi executada em 
outro computador o aplicativo pcp, após o estabelecimento 
da conexão entre os dois pontos o arquivo foi enviado com 
sucesso. 

Todo esse desenvolvimento mostra a utilidade e aplicação 
do protocolo XMPP sendo usado para troca de arquivos em 
redes P2P, e seu uso em aplicações de TV Digital interativa. 

O trabalho contribuiu para a inserção de novos recursos no 
âmbito da TV Digital no Brasil, o que ajudará no amadurec- 
imento do middleware Ginga. O trabalho serviu também 
como mais um experimento da evolução que a televisão deve 
sofrer ao decorrer dos próximos anos, ao ser tratada como 
uma nova plataforma de interatividade - o que é relevante 
por ser a TV, atualmente, a forma dominante para acesso a 
informação no Brasil. 
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